Secure token identification and medical rule-based authorization system

ABSTRACT

Systems and methods for rapid importation of data including temporally tracked object recognition. One of the methods includes receiving a request to authorize a prescription for a patient, the request being from a medical professional and the request being received of a network. The request is determined to be approved based on information associated with the patient. Transaction information is generated that is associated with the prescription, the transaction information specifying that the patient is authorized to obtain an associated pharmaceutical, and the transaction information being included in a transaction record associated with the patient. Authorization information associated with the prescription is generated, the authorization information being provided to a user device of the patient, and the authorization information enabling confirmation by an outside system that the prescription is authorized. Speech information associated with the prescription is presented on the user device of the patient, such that upon confirmation of presentation of the speech information, the transaction record associated with the patient is updated.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to, and is a continuation of, U.S.patent application Ser. No. 16/104,809 filed Aug. 17, 2018 which claimspriority to U.S. Prov. App. 62/546,739, filed Aug. 17, 2017. Theabove-recited applications are hereby incorporated herein by referencein their entirety for all purposes.

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are hereby incorporated by reference under 37 CFR 1.57.

This application hereby additionally incorporates by reference U.S.Patent Pub. 2018/0211059, which was filed on Jan. 23, 2018 and whichclaims priority at least to U.S. Prov. App. 62/510,160 filed on May 23,2017, in its entirety for all purposes.

TECHNICAL FIELD

The present disclosure relates to systems and techniques for security,data integration, and visualization. More specifically, this disclosurerelates to secure identification of computing systems and authorizingactions based on transference of secure information.

BACKGROUND

Patient health records are invaluable in determining a patient's currenthealth state and future health risk indicators. Medical information andassociated health records, however, are generated using complexdisparate proprietary systems and stored in different locations makingit difficult to access and compile. Existing systems also often provideinconsistent access to stored medical information. For example, ahospital may have many different proprietary computer systems that eachseparately record and maintain medical information of patients in uniqueproprietary formats. A medical professional can access the medicalinformation, but only on specific computer systems in specific wards ofthe hospital. This often results in requests for hard copies of medicalinformation pulled one at a time from various storage systems by avariety of personnel, causing significant wait times.

Complicating the provisioning of healthcare, a medical professional mayhave limited access to the sum total medical information associated witha patient. For example, a patient may have medical information stored atmultitudes of hospitals. In this example, the medical professional maynot have access to, or be unaware of, medical information at themultitudes of hospitals. As another example, the patient may visit aseries of emergency rooms for healthcare, and information from theseseries of visits may not be accessible to all medical professionals whosee the patient. With respect to a particular class of pharmaceuticals,such as pain medication, this inaccessibility of a patient's medicalhistory can create problems for medical professionals. For example, amedical professional may prescribe a pharmaceutical in the particularclass to a patient, without knowing the extent to which the patient hasreceived other prescriptions for a similar pharmaceutical.

A patient who has received a valid prescription, and thus has beenauthorized to obtain the associated pharmaceutical, may encounterobstacles to obtaining the pharmaceutical. For example, while at apharmacy the patient may be required to prove his/her identity to apharmacy. Additionally, the pharmacy may further require proof that theauthorization was validly granted by a medical professional. As anexample, the pharmacy may require that the prescription be confirmedwith the medical professional. While these proving steps may guardagainst improper access to pharmaceuticals, the prescription thereforemay not enable a patient to quickly obtain his/her authorizedpharmaceutical. Existing systems and schemes lack the technicalsolutions to enable automatic proof of identification of the patient tothe pharmacy, and automatic determination of the patient's validauthorization to obtain a pharmaceutical.

SUMMARY

Particular embodiments of the subject matter described in thisspecification can be implemented so as to realize one or more of thefollowing advantages. A system described herein can securely safeguardsensitive medical information of patients, while tightly integratingwith systems of patients, medical professionals, pharmaceuticalcompanies, and so on, to enable actions. As will be described, theactions enabled by the system can be based on strict adherence toauthorization information. An example action can include authorizing amedical professional's prescription of a pharmaceutical to a particularpatient. Another example action can include providing authorizationinformation to the particular patient's user device (e.g., mobiledevice) confirming the authorized prescription. In this way, theparticular patient can enter a pharmacy, and utilizing the authorizationinformation on his/her user device, can rapidly obtain an associatedpharmaceutical. The authorization information can confirm that theprescription was validly approved, and the user device can confirm anidentity of the particular patient (e.g., via biometric identification).Examples of authorization information include authorization tokens,encrypted or otherwise signed information, and so on.

The system described herein can further ensure that a totality of apatient's medical information is automatically analyzed prior to aprescription being authorized to a patient. The system can accessdisparate medical information, and automatically analyze the medicalinformation to ensure that the prescription is not associated withcontraindications. Additionally, the system can ensure that aprescription associated with a particular class of pharmaceuticals(e.g., painkillers) can be properly prescribed to a patient. As anexample, the system can identify whether the patient has visited othermedical professionals, emergency rooms, hospitals, and so on, to acquirepharmaceuticals in the particular class.

In accessing patient medical information, the system can optionallyensure strict trust conditions are enforced regarding visibility of thepatient medical information. As will be described below, the system canallow patients to ‘trust’ medical professionals and thereby provideaccess to specific portions (or the entirety) of the patient's medicalrecords and history. The trust can therefore enable a medicalprofessional to review detailed medical information of a patient.However, the system may similarly constrain access to portions of thepatient's medical information. For example, while the system can analyzemedical information prior to authorizing a prescription, the system canlimit an extent to which a medical professional can view the analyzedmedical information. That is, the system may indicate to the medicalprofessional that a pharmaceutical is associated with particularcontraindications, but may limit access to more detailed medicalinformation of a patient.

For particular pharmaceuticals, a pharmaceutical company may requirethat particular speech is presented (e.g., read aloud, shown) to apatient. As an example, particular cancer or narcotic drugs may requirewarnings, and so on, be presented to a patient. In contrast to examplecurrent methods, in which a pharmaceutical company may be required totelephone a patient to ensure that particular speech was read to thepatient, the system can automatically ensure that a particular patientwas presented the required speech. Indeed, the system can ensure thatthe speech was presented on the particular patient's user device, andthat the patient confirmed the presentation. In this way, the system canenable an end-to-end scheme for ensuring speech, such as information,questions for patients to respond to, and so on, can confidently bepresented to patients.

As will be described, the system can maintain communications withpharmaceutical systems, which can push updated speech rules associatedwith their pharmaceuticals to the system. As an example, the system canreceive information from a medical professional indicating that apatient is to be prescribed ‘Pharmaceutical A’. The system can thenobtain rules associated with ‘Pharmaceutical A’ from an associatedpharmaceutical company. Example rules may include the patient beingrequired to read particular information, watch a video, respond toquestions, and so on. The system can authorize the prescription uponsatisfaction of the rules.

Similarly, the system may de-authorize a prescription provided to apatient's user device upon violation of one or more rules. As anexample, the patient may be required to routinely communicate withhis/her medical professional, or perform a particular action such asmeasuring blood glucose levels, recording his/her weight, and so on. Thesystem may de-authorize a prescription such that the patient is unableto fill the prescription at a pharmacy. For example, the system mayde-authorize an authentication token stored on the patient's userdevice, or may update stored information reflecting thede-authorization.

In this way, the systems and methods improve the functioning of thecomputer and recite technical benefits. For example, the system canstrictly adhere to precise authorization rights, such that users (e.g.,patients) can rapidly perform actions. Without the techniques describedherein, pharmaceutical companies would be required to establish complexsystems and methods for ensuring observance of rules associated withtheir pharmaceuticals. As an example, a pharmaceutical company mayotherwise need to contact a patient to ensure that particularinformation was provided to them. Similarly, the pharmaceutical companymay need to approve prescriptive use of particular pharmaceuticals, andensure that medical professionals, pharmacies, and so on, closely followthese rules. In contrast, the system herein solves such technicaldeficiencies through utilization of authorization information.

Additionally, a patient operating his/her user device can view allauthorized prescriptions and optionally other medical information.Through simple interactions with the user device, and via use of thesystem, pharmacies can reduce frictions associated with issuingpharmaceuticals. That is, automatic processes to (1) validly identifythe patient, and (2) ensure the patient has authorization to obtain apharmaceutical, can be easily implemented. As will be described, thesystem can effectively issue credits, and debits, to patients that areassociated with prescriptions. In this way, the pharmacy can rapidlyreceive an indication from the system that the validly identifiedpatient is presently authorized to obtain an associated pharmaceutical.Similarly, the system may de-authorize a prescription, for example via adebit, and the issuance of the prescription may blocked in substantiallyreal-time to de-authorization.

Accordingly, in various embodiments, large amounts of data areautomatically and dynamically calculated interactively in response touser inputs, and the calculated data can be efficiently and compactlypresented to a user by the system. Thus, in some embodiments, the userinterfaces described herein are more efficient as compared to previoususer interfaces in which data is not dynamically updated and compactlyand efficiently presented to the user in response to interactive inputs.

Further, as described herein, the system may be configured and/ordesigned to generate user interface data useable for rendering thevarious interactive user interfaces described. The user interface datamay be used by the system, and/or another computer system, device,and/or software program (for example, a browser program), to render theinteractive user interfaces. The interactive user interfaces may bedisplayed on, for example, electronic displays (including, for example,touch-enabled displays).

Additional embodiments of the disclosure are described below inreference to the appended claims, which may serve as an additionalsummary of the disclosure.

In various embodiments, systems and/or computer systems are disclosedthat comprise a computer readable storage medium having programinstructions embodied therewith, and one or more processors configuredto execute the program instructions to cause the one or more processorsto perform operations comprising one or more aspects of the above-and/or below-described embodiments (including one or more aspects of theappended claims).

In various embodiments, computer-implemented methods are disclosed inwhich, by one or more processors executing program instructions, one ormore aspects of the above- and/or below-described embodiments (includingone or more aspects of the appended claims) are implemented and/orperformed.

In various embodiments, computer program products comprising a computerreadable storage medium are disclosed, wherein the computer readablestorage medium has program instructions embodied therewith, the programinstructions executable by one or more processors to cause the one ormore processors to perform operations comprising one or more aspects ofthe above- and/or below-described embodiments (including one or moreaspects of the appended claims).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an example of a medical authorization system.

FIG. 1B illustrates an example of a medical authorization system incommunication with outside systems.

FIG. 2A illustrates an example user interface presenting authorizedprescriptions of a patient.

FIG. 2B illustrates an example user interface to fill an authorizedprescription.

FIGS. 3A-3B illustrate speech associated with a prescription beingprovided on a user device of a patient.

FIG. 4 is a flowchart of an example process for generating transactionsin response to received prescriptions requests.

DETAILED DESCRIPTION

This specification describes a system (e.g., the medical riskauthorization system 100 described below) that can interface betweenpatients, medical professionals, pharmaceutical entities, payers (e.g.,insurance entities), and so on. As will be described, the system canauthorize prescriptions from medical professionals to patients. Forexample, a medical professional can indicate that a particularpharmaceutical is to be prescribed to a patient, and the system cananalyze the patient's medical information to authorize the prescription.Additionally, the system can enable pharmaceutical entities (e.g.,pharmaceutical companies, such as manufacturers) to specify one or morerules regarding controlled speech for particular pharmaceuticals. As anexample, upon receipt of a request to authorize a particularpharmaceutical to a patient, the system can obtain rules associated withthe particular pharmaceutical. As will be described, the system canrequest updated rules from an associated pharmaceutical entity, and canenforce the rules prior to the particular pharmaceutical beingauthorized to the patient. For example, the patient may be required toreview information, watch a video, respond to questions, or take otheractions as will be described. The system can subsequently update logsassociated with the patient, for example update a blockchain basedrecord as will be described.

The system, as will be described, can represent a medical network whichcan credit (e.g., authorize a patient to perform an action, such asobtain a pharmaceutical) or debit (e.g., indicate that the patient hasperformed the action, or de-authorize the credit) particular medicalactions. As an example, upon a medical professional indicating that apatient is to receive a prescription, the system can update maintainedinformation to indicate the patient's authorization. In this way, thesystem may optionally authorize patients to obtain pharmaceuticals basedon received approval for associated prescriptions from medicalprofessionals. Optionally, and as described above, the system mayanalyze medical history of the patient prior to the authorization. Aswill be described in more detail below, the system can optionallymaintain information associated with each patient indicating atransaction record. In this specification, a transaction record includesany information indicative of authorizations or de-authorizations ofprescriptions. The system can review the transaction record to ensurethat the patient is not presently taking pharmaceuticals withcontraindications to a potential prescription. Optionally, a transactionrecord can specify constraints associated with each prescription.Example constraints can include a number of pills of a pharmaceuticalthat the patient is authorized to receive, dosage, length associatedwith prescription, and so on.

Upon authorization of a prescription, and as described above, the systemcan update a transaction record associated with a patient. In this way,the system can ensure that a record of the authorizations is maintained.This authorization can propagate from the system to the patient, andoptionally prescribing medical professional, such that the patient canutilize the authorization to obtain (e.g., fill) the prescription. Aswill be described, the system can generate an authorization token forstorage by a user device of the patient, with the authorization tokenbeing utilized to confirm valid authorization for a particularpharmaceutical. As another example, the system can electronically signinformation to be stored on the user device of the patient. For example,the system can utilize a public key/private key based signing scheme,such that outside systems (e.g., a pharmacy system) can ensure that thereceived information emanated from the system.

The authorization information can be utilized by a pharmacy asconfirmation of the patient's prescription. As will be described, thepatient's user device can execute an application (e.g., an electronic‘app’ downloaded from an application store) to present authorizedprescriptions to the patient. This application can receive informationspecifying authorized prescriptions from the system. Additionally, theapplication can store associated authorization information. To ensurethat the application is only accessible by a specific patient, theapplication can require biometric authentication, passwordauthentication, and so on.

Therefore, the patient can travel to a pharmacy, and utilize theapplication to obtain a pharmaceutical. For example, the patient caninteract with his/her user device to provide authorization informationto a system associated with the pharmacy. This authorizationinformation, as described above, can confirm the patient's authorizationto obtain an associated prescription. Subsequently, the application canupdate to indicate that the prescription has been filled. For example,the application can remove the prescription from a presentation of thepatient's remaining prescriptions. In this way, the patient will beunable to access the prescription until a medical professionalauthorizes a new prescription.

Similarly, upon the pharmacy verifying that the authorizationinformation is valid, the system can update to indicate that theprescription has been filled. For example, a transaction record of thepatient can be updated to specify the filling of the prescription (e.g.,a debit). With respect to the example of a blockchain, the system mayinclude the transaction in the blockchain based network. In this way,the patient will be unable to utilize the prescription again. That is,the authorization information associated with the prescription will nolonger be valid. Based on the updating of the transaction record, thesystem can provide information to the pharmacy rejecting the validity ofany invalid the prescription. While the example of a blockchain isdescribed above, it should be understood that a transaction record maybe stored, or maintained, via different data storage techniques. Forexample, the system can store secure information in a database, such asstructured or unstructured information.

Additionally, the system may store information indicative of authorizedprescriptions, but not store potentially sensitive prescriptioninformation. For example, upon authorization of a prescription, thesystem can generate authorization information to be provided to a userdevice of a patient. The system can store information indicative of thisauthorization information, for example an encrypted hash of theinformation, a unique identifier, and so on. The authorizationinformation stored by the user device of the patient may instead store(e.g., in an encrypted form) specific information associated with theprescription. For example, the specific information can include a nameof the prescription, a number of pills, and so on. In this way, thepatient can cause the decryption of the authorization information, andprovide the specific information to the pharmacy. Example decryptionschemes may be associated with proof of identity of the user, such asbiometric identification, password, and so on. The pharmacy can thenrequest that the system confirm the prescription is valid (e.g., thesystem can confirm the information indicative of the authorizationinformation).

Optionally, a secret sharing scheme may be utilized with the system,user device, and/or pharmacy. As an example, an authorized prescriptionmay be separated into a number of secret shares according to a secretsharing scheme. The system may retain a particular secret share, whileproviding a different secret share to the user device. The resultingsecret (e.g., the prescription) may be generated upon a user beinglocated at a pharmacy attempting to fill the prescription. For example,a pharmacy system associated with the pharmacy may receive the secretshare from the patient's user device. In this example, the pharmacysystem can provide the received secret share to the system. The systemcan then confirm the validity of the secret share, and generate theprescription. This secret can be provided to the pharmacy system, whichcan present the prescription to a pharmacist to fill. Optionally, thepharmacy system may receive both secret shares and generate theprescription.

While the description herein describes authorizing prescriptions, itshould be understood that the system can be utilized for any medicalequipment or necessity. For example, a medical professional can indicatethat a patient requires use of a wheelchair. The system can then updateto reflect that the patient is authorized for the wheelchair. Thisauthorization may be utilized by a pharmacy, or other medical entity(e.g., medical equipment store), to provide the patient with awheelchair. Additionally, the system may enable integration with medicalpayers, such that a cost associated with a prescription or medicalequipment is automatically provided to a medical payer. As an example,the system can indicate to a pharmacy that a patient is authorized toobtain a particular pharmaceutical. The system can also provideinformation to a medical payer of the patient indicating that thepatient is filling the pharmaceutical. The medical payer can thenrapidly approve some, or all, of the associated cost of theprescription. This approval can be provided to the pharmacy, which mayremove the approved portion of the cost from the patient's in-pharmacybill.

The system described herein can therefore be utilized to overcomepresent technical hurdles associated with healthcare. For example, apatient can avoid being required to prove his/her identity, and thepharmacy can avoid requirements regarding confirming prescriptions withmedical professionals. Instead, the patient can confirm his/her identitythrough interaction with the user device. For example, the patient canplace a thumbprint on the user device as biometric confirmation that theuser device belongs to the patient. As another example, the user devicemay determine a voice print, or other voice recognition informationassociated with a user of the user deice. In this example, biometricconfirmation may be based on the user device successful determining thatthe voice print corresponds to the patient. Optionally, the user devicemay offload processing of the voice print to an outside system (e.g.,via a network, such as the internet). Similarly, the user device canutilize facial recognition technology, and so on, to confirm theidentity of the patient. Additionally, the system can confirm thevalidity of the authorization information such that medical professionalconfirmation is unnecessary.

However, for particular types of pharmaceuticals a medical professionalmay request that his/her confirmation be required prior to a pharmacyproviding pharmaceuticals to a patient. For example, the system mayreceive information from a pharmacy requesting confirmation of aprescription. The system can then cause a prompt on the prescribingmedical professional's user device requesting that the medicalprofessional confirm the prescription. For example, the medicalprofessional may be required to place his/her thumbprint on a reader.Upon this final authorization by the medical professional, the systemcan provide information to the pharmacy confirming the validity of theprescription.

FIG. 1A illustrates an example of a medical authorization system 100.The medical authorization system 100 can be a system of one or morecomputers, one or more virtual machines executed on a system of one ormore computers, and so on. Optionally, the medical authorization system100 may include virtualized processors, memory, storage systems, and soon, which may fluctuate according to demand. As described above, themedical risk authorization system 100 can receive requests 102 toauthorize prescriptions, and generate transactions 112 in response tothe requests 102. A transaction 112 may indicate approval of the request102, or optionally denial of the request 102. For example, thetransaction may specify a credit associated with a patient (e.g., anapproved prescription). Additionally, a transaction 112 can includede-authorizing a previously authorized prescription (e.g., a debit). Forexample, a patient may have received a pharmaceutical associated with aprescription. In this example, the medical risk authorization system 100can generate a transaction 112 indicating that the prescription is notvalid.

FIG. 1A illustrates a pharmaceutical module 118 being provided to themedical risk authorization system 100. In some embodiments, the medicalrisk authorization system 100 can be configured according to a type ofpharmaceutical. For example, prior to responding to requests 102 (e.g.,as will be described), the medical risk authorization system 100 may berequired to receive pharmaceutical module 118. This module 118 may thenbe loaded, for example into memory of the system 100. Optionally, themedical risk authorization system 100 may store multitudes ofpharmaceutical modules. In this example, the medical risk authorizationsystem 100 can receive selection of a pharmaceutical (e.g., from anoutside system or user) and access the associated module. Thepharmaceutical module 118 can cause different behavior of the system 100according to the pharmaceutical associated with the module 118. In thisway, the medical risk authorization 100 may not be configured to performthe functionality described herein absent the pharmaceutical module 118.Additionally, and as will be described, a patent's user device mayobtain an application for execution on the user device. For example, theapplication may be obtained from an online ‘app’ store. Optionally, theapplication may be specific to a type of pharmaceutical. For example,the pharmaceutical module 118 executing on the medical riskauthorization system 100 may be configured to only communicate with anapplication on a user device associated with a same pharmaceutical.

An example pharmaceutical module 118 may relate to opiates. In thisexample, the medical risk authorization system 100 may perform specificfunctionality related to opiates. Example functionality may includedetermining whether a patient being prescribed opiates has receivedopiates from other prescribers. For example, the medical riskauthorization system 100 may analyze transactions 112 as will bedescribed. Additional pharmaceutical modules may relate to thalidomide,lenalidomide, pomalidomide, and so on.

Thus, the particular pharmaceutical module 118 can cause varyingbehavior of the medical risk authorization system 100. With respect toan example pharmaceutical, the medical risk authorization system 100 mayonly authorize that the pharmaceutical is to be obtained from specificpharmacies. Additionally, the medical risk authorization system 100 mayrequire that specific speech be presented to a patient uponauthorization of the pharmaceutical. Optionally, the medical riskauthorization system 100 may configure the systems that it communicateswith. For example, FIG. 1B described below illustrates the medical riskauthorization system 100 in communication with pharmaceutical entities(e.g., entity servers 150A-150N). These pharmaceutical entities mayprovide rules to the system 100 to enforce when authorizing a particularprescription. Example rules may include specific speech, or specificconstraints (e.g., the patient may have to check in with a medicalprofessional periodically). In this example, the particularpharmaceutical module 118 may limit the pharmaceutical entities whichthe system 100 is authorized to receive communications from.

A request 102 can specify that a particular patient is to be approvedfor a particular pharmaceutical. The system 100 can receive the request102 from a user device or system associated with a medical professional.For example, a medical professional can examine a patient, and utilize auser device to specify information for a prescription to be provided tothe patient. Optionally, the medical risk authorization system 100 mayimplement, or be in communication with, a web application utilized bythe medical professional. The web application can present a userinterface on the user device of the medical professional, which canenable a specification of a prescription. Optionally, the medicalprofessional's user device may execute an application that presents auser interface enabling specification of a prescription.

As an example, the user interface can include textual fields for themedical professional to specify a name of a prescription. The medicalprofessional may further specify constraints associated with theprescription. Example constraints may include a number of pills thepatient is authorized to receive, a number of refills the patient canobtain, and so on. Optionally, constraints may indicate actions that thepatient is to perform. For example, the medical professional can requirethat the patient weigh himself/herself periodically while taking thepharmaceutical. As another example, the medical professional can requirethat the patient measure blood glucose while taking the pharmaceutical.As will be described, the patient may therefore be required to performthe specified actions, and provide information to the medical riskauthorization system 100 in response. The medical risk authorizationsystem 100 can generate notifications to be provided to the medicalprofessional, for example if the actions are not being performed. Themedical authorization system 100 may further cause a prescription forsame, or similar, pharmaceuticals to be de-authorized if the patientdoes not perform the actions.

Each request may be provided with information identifying a requestingmedical professional. In this way, the medical risk authorization system100 may ensure that requests 102 are being provided from authorizedusers with authority to grant prescriptions. For example, the medicalrisk authorization system 100 may store user account information formedical professionals. In this example, a medical professional canprovide user account information, such as a user name and password, tothe medical authorization system 100. As another example, the medicalrisk authorization system 100 may require biometric authorization from amedical professional. For example, the medical professional may berequired to place his/her thumb on a thumbprint reader, or a facialrecognition process may be required. Optionally, the medicalprofessional's voice print (e.g., voice recognition) may be required. Aswill be described below, resulting transactions 112 may specifyprescribing medical professionals, such that their prescriptions may beaudited.

The medical risk authorization system 100 includes an approval engine104 that can receive a request 102 and determine whether the request 102is to be approved. As described above, optionally the medical riskauthorization system 100 may automatically approve requests 102 receivedfrom medical professionals. That is, medical professionals may beassumed to understand risks associated with pharmaceuticals along with apatient's history. However, optionally the approval engine 104 cananalyze medical information associated with a patient and identifywhether a request 102 is to be authorized. In some embodiments, theapproval engine 104 may access, or provide requests to, state databases.The state databases may be utilized to verify amounts of certain typesof pharmaceuticals prescribed to a patient. Example pharmaceuticals maybe opioid medications for a prescription drug monitoring program.Similarly, the state databases may verify amounts of certain types ofpharmaceuticals prescribed by a medical professional. These amounts maybe determined to exceed one or more limits, and thus a request may bedenied.

Optionally, the medical risk authorization system 100 may have access toall of a patient's medical history. For example, the medical riskauthorization system 100 may maintain information indicating locationsat which each patient's medical history is stored. As patient's movebetween hospitals, private practices, emergency rooms, and so on,disparate medical records can be created by different medicalprofessionals. The medical risk authorization system 100 may be able tosecurely access medical information stored on computers, servers, and soon, at each of these differing locations. As an example, a secure healthprotocol may be utilized that allows for such secure access toinformation. The medical risk authorization system 100 may thereforestore information indicating locations at which to access a patient'smedical history. In some embodiments, the medical risk authorizationsystem 100 may provide a request for the patient's medical informationto an outside system. The outside system may determine whether thepatient has consented to the system 100 obtaining the patient's medicalinformation. The outside system may also determine whether the patienthas consented to a requesting medical professional providing medicalcare to the patient. For example, the patient may be required toindicate trust to the medical professional.

Optionally, the medical risk authorization system 100 can store some, orall of, a patient's medical history. That is, as differing medicalprofessionals see a patient, the medical professionals can access a webapplication associated with the medical risk authorization system 100.The system 100 can therefore store the sensitive medical information,while optionally being able to access medical information stored locallyon outside computer systems, servers, and so on. In this way, themedical risk authorization risk system 100 can review a patient'smedical history while preserving the sensitive information to arequesting medical professional. For further description of a healthprotocol, and a system that enables such secure storage and access ofmedical information, see U.S. Patent Pub. 2018/0211059 which isincorporated by reference in its entirety.

Based on a patient's medical history, the approval engine 104 candetermine whether a request 102 for a prescription is to be approved.For example, the approval engine 104 can analyze contraindicationsassociated with a prescription and other pharmaceuticals being taken bythe patient. As another example, the approval engine 104 can determinewhether the patient has any allergies that may cause problems with theprescription. Since the medical risk authorization system 100 has accessto a patient's medical history, the system 100 can identify anyindications of allergies. In contrast, a medical professional may not beaware of certain allergies, or the patient may fail to mention them tothe medical professional. As another example, the approval engine 104can determine whether the prescription violates particular limitationsassociated with the prescription. Example limitations can include thepatient being pregnant, younger than a certain age, having certainfamilial medical history, and so on.

For implementations in which the medical risk authorization system 100does not have access to a patient's full medical history, the approvalengine 104 can analyze prior transactions 112 associated with thepatient. Since each transaction can indicate a particular prescriptionauthorized for the patient, the approval engine 104 can identify allpharmaceuticals being utilized by the patient. Therefore, the approvalengine 104 can determine whether a combination of the prescription withthe currently utilized pharmaceuticals is associated with anycontraindications. Furthermore, the approval engine 104 can identifywhether the patient has exceeded prescriptions for a particular class ofpharmaceutical. For example, the particular class may include opiates.As an example, a patient may attempt to obtain opiates from multiplemedical professionals. As described above, the patient may visitemergency rooms, hospitals, and so on, in an attempt to obtain opiateswhile obfuscating the attempts from each medical professional. Since thepatient's transactions 112 will, in this example, indicate that thepatient has received prior prescriptions for opiates, the approvalengine 104 can deny a request for additional opiates.

In this way, the approval engine 104 may determine whether the patienthas exceeded one or more thresholds associated with a pharmaceutical(e.g., opiates). The engine 104 may, as described above, determinewhether the patient has received greater than a threshold quantity ofthe pharmaceutical, or greater than a threshold in a certain timeperiod. The engine 104 may also determine whether the patient hasvisited more than a threshold number of prescribing medicalprofessionals (e.g., within a particular time period). The threshold mayalso relate to a threshold number of prescriptions given by a particularmedical professional to patients. For example, if the medicalprofessional has exceeded a threshold, the engine 104 may deny arequest.

As will be described in more detail below, with respect to FIG. 1B, themedical risk authorization system 100 can be in communication withpharmaceutical systems. For example, the pharmaceutical systems can pushrules to be enforced with respect to their pharmaceuticals. As describedabove, example rules can include particular speech being provided to thepatient. Examples rule can also include particular speech provided to amedical professional. For example, speech to provide a patient or speechfor the medical professional to receive. Example speech can includewritten information regarding a pharmaceutical, a video, aquestionnaire, an interactive game confirming the speech was receivedand understood, and so on. Since the pharmaceutical systems can pushinformation to the system 100, or optionally the system 100 canperiodically pull information, the pharmaceutical systems can provideupdated contraindications with respect to their pharmaceuticals. Theapproval engine 104 can utilize this real-time contraindicationinformation to inform whether a request 102 is to be approved or denied.For example, a pharmaceutical company may have access to recent researchregarding a pharmaceutical. To ensure that the approval engine 104utilizes current, or fresh, information, the approval engine 104 canobtain a most recent version of the information from a pharmaceuticalsystem.

Optionally, if the approval engine 104 denies a request 102, the medicalrisk authorization system 100 can provide information identifying thedenial to a requesting medical professional. The medical professionalcan then cause an override of the denial, such that a prescription isauthorized. The approval engine 104 can provide information indicatingparticular reasons why the request 102 was denied. For example, theapproval engine 104 can specify that the patient is taking one or morecontrary pharmaceuticals. As another example, the approval engine 104can specify that the patient has exceeded a limit for a particular typeof pharmaceutical, and so on.

The medical risk authorization system 100 includes a transaction engine110 that can generate transactions 112 in response to approvals ofrequests 102. A transaction 112 can include information describing anapproved request 102. For example, a transaction 112 can indicate that aparticular patient is authorized to obtain a particular pharmaceuticalwith particular constraints. Similar to a credit being issued to, forexample, a merchant indicating that a particular credited value has beenauthorized for the merchant, the transaction 112 can record an approvedprescription request 102. In this way, a pharmacy or other requestingentity may query the medical risk authorization system 100 forconfirmation of the validity of a prescription. The medical riskauthorization system 100 can respond and indicate some, or all of, theinformation included in the transaction 112. Example information caninclude a name of a prescribing medical professional, a dosageassociated with the prescription, a length of time associated with theprescription, constraints associated with the prescription, and so on.Optionally, the medical risk authorization system 100 can confirm thatthe transaction 112 was generated based on a request from a validmedical professional, but not indicate a name of the medicalprofessional.

As illustrated in the example of FIG. 1A, the medical risk authorizationsystem 100 is in communication with a transaction record informationdatabase 116. As will be described, the transaction record informationdatabase 116 can store transaction records associated with patients. Asdescribed above, a transaction record can include information specifyingtransactions associated with each patient, thereby generating a recordof the prescriptions authorized to each patient. The transaction recordinformation database 116 may be a database, a distributed database, astorage system, and so on. For example, the transaction recordinformation database 116 can be a MySQL, NoSQL, and so on, database.Optionally, the database 116 may store objects associated with eachpatient, such as information included in JavaScript Object Notation(JSON). In this example, one or more transactions associated with eachpatient may each be encapsulated in a JSON file, with the includedinformation specifying prescription information associated with the oneor more transactions.

As described above, an example transaction 112 may specify a prescribingmedical professional. An example transaction 112 may also specify a nameof a pharmaceutical. An example transaction 112 may also specify alength of time to take the pharmaceutical. Additional information alsobe included in the example transaction 112. The transaction recordinformation database 116 can therefore maintain these records for lateraccess. For example, a pharmacy may access the transaction recordinformation database 116. Additionally, the approval engine 104 mayutilize the database 116 to determine whether to approve a receivedrequest 102. For example, the approval engine 104 can analyzeprescriptions that are currently being taken by a patient. To identifysuch prescriptions, the approval engine 104 can determine whichprescriptions are indicated as being active.

As an example, the approval engine 104 can identify all transactionsassociated with a patient, or transactions within a threshold period oftime. The approval engine 104 can then filter the identifiedtransactions according to a time at which the patient obtained theassociated pharmaceuticals, and a length of time the patient is to takethe pharmaceutical. As described above, a transaction 112 can indicatethat a credit to a patient, that is that a prescription is authorized.Similarly, the transaction record information database 116 can storedebit information, indicating that a prescription has been filled or isno longer valid. In this way, the approval engine 104 can determine atime at which the prescription was filled, and can then identifycurrently active prescriptions. Optionally, the approval engine 104 mayprovide requests to an application executing on a user device of a user.This application may store information indicating prescriptions beingutilized by a patient operating the user device. Thus, the approvalengine 104 can identify currently active prescriptions. Additionalinformation related to the application is described in more detailbelow.

The transaction record database 116 may optionally be implemented as ablockchain storing transaction information. Since a transaction caninclude a prescription being authorized, or de-authorized, to a patient,the blockchain can maintain a record associated with all authorizedprescriptions. The medical risk authorization system 100 can thereforereceive a request from a pharmacy regarding validity of a prescription,and utilizing the blockchain can determine whether the prescription isstill authorized. Optionally, the blockchain network may be accessibleto outside systems, such as systems associated with pharmacies. Thesesystems may receive authorization information from user devices ofpatients, and based on the authorization information may access theblockchain network to determine whether the associated prescription isvalid. For example, the authorization information may specify encryptedhash information associated with an initial transaction generated inresponse to approval of a prescription. These outside systems mayanalyze the blockchain network to determine whether any subsequenttransactions associated with the encrypted hash information caused theprescription to be invalid. In this way, the validity of a prescriptioncan be rapidly identified via an automatic lookup of the blockchainnetwork.

As a patient utilizes his/her prescription, the patient may obtain oneor more refills. For example, a medical professional may prescribe aparticular number of refills (e.g., 3, 4, and so on). The blockchain maythus reflect a transaction that indicates a refill. For example, apharmacy system (e.g. system 140 described below) may provide atransaction indicating the refill. As will be described below, thepatient's user device may transmit authorization information 114associated with the prescription to the pharmacy. If the patientrequests a refill, the pharmacy system may analyze the blockchain toidentify a number of refills associated with the prescription. Thepharmacy system can then issue another transaction indicating a newrefill if the patient has remaining refills. Optionally, the issuedtransaction may be analyzed by a smart contract or oracle. For example,the oracle may determine that the pharmacy system is authorized to issuetransactions. The oracle may then provide information to a smartcontract associated with the blockchain network. The smart contract cancause generation of a new block, or a transaction within a proposedblock, recording the refill. Example information to record may include aunique identifier associated with the prescription. The information mayfurther include a unique identifier associated with the applicationexecuting on the patient's user device. In some embodiments, a uniqueidentifier associated with the patient may be recorded. In this way, theblockchain may record the prescription information of a plurality ofpatients.

FIG. 1B illustrates an example of a medical authorization system 100 incommunication with outside systems. As described above, with respect toFIG. 1A, the medical risk authorization system 100 can respond torequests for approval of prescriptions, and generate transactionsrecording approved prescriptions. As illustrated in FIG. 1B, the medicalrisk authorization system 100 can be in communication with a medicalprofessional user device 130, a patient user device 120, a pharmacysystem 140, and/or entity systems A-N 150A-150N. Examples of an entitysystem can include a pharmaceutical company system, a medical payersystem (e.g., insurance system), and so on. Via automated interactionswith each of the outside systems, the medical risk authorization system100 may enable, at least in part, the technical benefits describedherein.

As illustrated, trust information 132 is indicated between the medicalprofessional user device 130 and the patient user device 120. Trust, asdescribed above, can represent that a patient confirmed a medicalprofessional is authorized to access medical information associated withthe patient. For example, upon meeting with a medical professional for afirst time, the patient can utilize his/her user device 120 to providetrust to the medical professional 130. As an example, the patient canconfirm his/her identity on the user device 120. An applicationexecuting on the user device 120 can confirm that trust is to beestablished with the medical professional. Optionally, the patient canconsent to a trust relationship. The trust relationship can beassociated with a group of medical professionals, for example at ahospital or other medical provider.

The trust information 132 can be utilized by the medical riskauthorization system 100 to confirm that the medical professional isauthorized to access medical information of the patient. Additionally,the trust information 132 can be utilized to record uniquely identifyinginformation associated with the patient user device 120. For example,when the medical risk authorization system 100 provides authorizationinformation 114 confirming a prescription to the patient user device120, the trust information 132 can be utilized to confirm that thepatient user device 120 belongs to the patient. Further descriptionrelated to trust information 132 is described in U.S. Patent Pub.2018/0211059, which is incorporated by reference in its entirety.

As described in FIG. 1A, the medical risk authorization system 100 canapprove requests 152 for prescriptions. Upon approval of a receivedrequest associated with a patient, the medical risk authorization system100 can generate authorization information 114 to be provided to thepatient's user device (e.g., device 120). In implementations in whichtrust information 132 is maintained, the medical risk authorizationsystem 100 can identify a particular patient user device 120 to receivethe authorization information 114 based on an identity of theprescribing medical professional and patient. For example, the system100 can identify a medical professional indicated in the request toauthorize a prescription. The system 100 can then obtain an indicationof a patient as specified in the request. The system 100 can determinewhether the patient has indicated trust to the medical professional.Upon a positive determination, the system 100 can obtain uniqueidentifying information associated with a user device utilized toindicate trust to the medical professional. The system 100 can thenprovide the authorization information 114 to the identified user device.In implementations in which trust information 132 is not utilized, thesystem 100 can store user account information associated with patients.Based on an identity of a patient specified in a request from themedical professional user device 130, the system 100 can access useraccount information associated with the patient. Subsequently, thesystem 100 can provide the authorization information 114 to anapplication associated with presentation of prescription information onthe patient user device 120. For example, the system 100 can push theauthorization information 114 to a user account associated with thepatient. The patient user device 120 can then receive the information114.

Optionally, the medical risk authorization system 100 can provide theauthorization information 114 to the medical professional user device130. An application executing on the user device 130 can then providethe authorization information via a local network to the patient userdevice 120. For example, the medical professional user device 130 canidentify user devices within a threshold range, such as via Bluetooth,Near Field Communications, a locally generated Wi-Fi network, and so on.The medical professional user device 130 can then provide theauthorization information 114 to an application executing on the patientuser device 120. In this way, the authorization information 114 issubstantially guaranteed to be provided to the correct patient's userdevice 120.

Example authorization information 114 can include an authorizationtoken, such as an OAuth token, a JSON token, and so on. In the exampleof an OAuth token, the authorization information 114 can enable a thirdparty to access a portion of a transaction record associated with thepatient. For example, the authorization information 114 can be providedto a pharmacy system 140, which can utilize the authorizationinformation 114 to verify the validity of the associated prescription.As an example with respect to an OAuth token, the pharmacy system 140may provide the OAuth token to the medical risk authorization system100. Since the token authorizes the third party, which in this exampleis the pharmacy system 140, to access information associated with theprescription, the medical risk authorization system 100 can respondconfirming or denying the prescription.

Additional authorization information 114 may include electronicallysigned information according to a public key/private key scheme. Forexample, the authorization information 114 can describe a prescriptionauthorized to a patient utilizing the patient user device 120. Thisdescription can be signed according to a private key associated with themedical risk authorization system 100. The pharmacy system 140 canreceive the electronically signed information, and confirm that theinformation is signed by the medical risk authorization system 100according to a public key of the system 100. In this way, the pharmacysystem 140 can be assured that the system 100 validly issued theprescription.

However, with the electronic signing scheme described above, theprescription may not have assurances that it is still valid. Forexample, the prescription may have been revoked by a medicalprofessional, or the prescription may have been filled. Therefore,optionally the electronically signed information can specify a uniqueidentifier associated with the prescription. The pharmacy system 140 canprovide this unique identifier to the medical risk authorization system100. Upon receipt, the medical risk authorization system 100 can analyzea transaction record associated with the patient, and ensure that theunique identifier is still valid. Similarly, this unique identifier maybe analyzed based on a blockchain (e.g., as described in FIG. 1A). Forexample, transactions within the blockchain may be analyzed to determinewhether the prescription was de-authorized.

The pharmacy system 140, as illustrated, can therefore receiveapproval/prescription information 142 from the medical riskauthorization system 100 confirming that a prescription is valid.Optionally the information 142 can describe a prescription, such as aname of a prescribing medical professional, a name of an associatedpharmaceutical, constraints associated with the pharmaceutical, and soon. For example, the authorization information 114 may be anauthorization token associated with a prescription, and the system 100can provide the specific prescription information to the pharmacy system140. In this way, the medical authorization system 100 can be the onlysystem authorized to describe specifics of prescriptions. Optionally theinformation 142 can indicate approval of a particular prescription, butnot include specifics of the particular prescription. In this example,the patient user device 120 may provide specifics of a prescription tothe pharmacy system 140. For example, the specific information may beelectronically signed by the medical risk authorization system 100. Thesystem 100 can therefore confirm that the prescription is stillauthorized to the patient. A pharmacist utilizing the pharmacy system100 can thus fill the prescription according to the signed informationreceived from the patient user device 120.

An entity system 150, such as a pharmaceutical company system, candefine rules 154 associated with their pharmaceuticals. An example rule154 may include the presentation, or otherwise providing of, particularspeech to a patient or medical professional. For example, the patientmay be required to read particular text. The patient may also berequired to watch a video. The patient may also be required to have adiscussion with his/her medical professional or pharmacist. The patientmay also be required to respond to a questionnaire, play a gameassociated with the speech, and so on.

The rules 154 may be utilized by the medical risk authorization system100 to enforce the speech that the pharmaceutical company indicates asbeing required for utilization of particular pharmaceuticals. Togenerate these rules 154, particular templates may be utilized by anentity system 150. An example template may specify particular text to bepresented on a patient user device 120, or specify a location (e.g.,network address) at which particular text is located. Similarly, anexample template may specify video to be presented. An example templatemay further be associated with interactive user interface information.Example interactive user interface information may includequestionnaires, interactive games describing risks and benefits of apharmaceutical, and so on.

As illustrated in FIG. 1B, the medical risk authorization system 100 mayprovide a request 152 to an entity system 150A. The request 152 may berelated to speech for one or more pharmaceuticals. For example, therequest 152 may be a request for speech information 154 associated witha prescribed pharmaceutical for a patient. The medical riskauthorization system 100 may optionally cache speech information 154, ormay provide a request to a pharmaceutical company system 150A subsequentto each authorized prescription. In this way, the system 100 can beassured that up-to-date speech information 154 is presented to a patientuser device 120. The speech information 154 can then be presented via anapplication executing on the patient user device 120.

Optionally particular rule information 154 may be specified indicatingconstraints associated with a prescription. For example, the ruleinformation 154 can specify actions that a patient is to perform whiletaking a pharmaceutical. As an example, the patient may be required toutilize his/her mobile device to obtain an image of pills beingconsumed. In this way, dosage may be tracked. For example, a user deviceof the patient may monitor an amount of pills remaining in a currentbottle. If the patient does not obtain pictures of the pills beingconsumed, or a video of swallowing, then the system 100 may de-authorizesubsequent refills. Optionally, the system 100 may cause notificationsto be triggered to a prescribing medical professional regarding pillsnot being taken.

As another example, an example action can include requiring that thepatient weigh himself/herself, measure particular biometric markers, andso on. This rule information 154 may then be enforced by the medicalrisk authorization system 100. For example, the medical riskauthorization system 100 can store the rule information 154 (e.g., inthe transaction record information database 116). The medical riskauthorization system 100 can then monitor conformity of the patient'sactions to the rule information 154. With respect to the example of thepatient weighing himself/herself, the patient can be required to enterweight measurements into an application executing on the patient's userdevice 120. Optionally, the application may communicate (e.g., viaBluetooth, or near field communication) with a smart scale. Optionally,the medical risk authorization system 100 can receive thesemeasurements, and store them as being associated with a medical historyof the patient. For example, in implementations in which the medicalrisk authorization system 100 maintains, or is able to locate, medicalinformation of each patient as described above. Optionally, the medicalrisk authorization system 100 can receive metadata from the patient userdevice 120 confirming that a weight measurement was performed by thepatient. This metadata may not include specific medical information, butbe utilized to determine conformity with the rule information 154. Thesensitive medical information may be stored by the patient's user device120, and optionally shared directly with a medical professional.

In addition to an entity system 150A specifying rule information 154, amedical professional can further indicate constraints. For example, themedical professional can indicate actions that a patient is to performwhen providing a request to authorize a prescription. For example, themedical professional can require that the patient check-in periodicallywith the medical professional while taking a pharmaceutical.

Adherence to this rule information 154 may inform approvals ofprescriptions for patients. For example, if a patient is determined notto be performing actions indicated by the rule information 154, themedical risk authorization system 100 can deny requests for similarpharmaceuticals. As an example, the medical risk authorization system100 can provide information to a medical professional that a patient hasnot been following the rule information 154. Additionally, the medicalrisk authorization system 100 may cause an authorized prescription to bede-authorized based on failure of a patient to adhere to the ruleinformation 154. For example, an authorized prescription may indicatethat a patient has a number of refills of a pharmaceutical. If thesystem 100 determines that the patient is not conforming to the ruleinformation 154, the system 100 may cause remaining refills to bede-authorized. In this way, if a pharmacy system 140 attempts tovalidate the prescription, the system 100 can indicate that theprescription is no longer valid. Optionally, the system 100 may provideinformation to the medical professional user device 130 indicating thata patient is not performing required actions. The medical professionalcan be required to confirm that a prescription is to be de-authorized.

Optionally, the medical risk authorization system 100 may optionally beassociated with only specific pharmacies. For example, one or moresystems 100 may be utilized, with each system working with specificpharmacies. In this way, each pharmacy may be able to confirmprescriptions of patients that utilize the pharmacy, but outsidepharmacies may be unable to fill the prescriptions.

FIGS. 2A-3B illustrate example user interfaces presented on patient userdevices. The user interfaces can be examples of interactive userinterfaces generated by applications executing on the user devices. Forexample, the applications may be obtained from electronic applicationstores, and may be associated with healthcare of users of the userdevices. As another example, the user interfaces may be generated, atleast in part, via web applications executing on outside systems. Theuser devices may access the web applications, and present (e.g., render)user interface information received from the web applications. As willbe described, the user interfaces can enable a healthcare wallet. Thehealthcare wallet may allow a user to review authorized prescriptions.The healthcare wallet may also confirm that a prescription is to befilled. The healthcare wallet may also cause, or otherwise enable,payment of a filled prescription to be provided. As an example, paymentmay be obtained from an electronic wallet on a patient's user device.For example, payment may be obtained from a wallet enabling access tocredit card or debit card information of the patient. The wallet mayalso optionally enable payment directly via an outside entity (e.g., aninsurance company).

FIG. 2A illustrates an example user interface 200 presenting authorizedprescriptions of a patient on a user device 120 of the patient. Asdescribed above, with respect to FIGS. 1A-1B, the medical riskauthorization system 100 can receive requests 102 to authorizeprescriptions, and generate transaction information in response.Additionally, the medical risk authorization system 100 can provideauthorization information 114 to the patient's user device 120confirming validity of the requested prescription.

As illustrated in FIG. 2A, the medical risk authorization system 100 isillustrated as being in communication with a medical professional userdevice 130 via a network 160 (e.g., the internet). The system is alsoillustrated as being in communication with the patient's user device 120via the network. Optionally, the network 160 may utilize a healthcommunication protocol as described above. Based on approval of arequest 102, the patient's user device 120 can receive authorizationinformation 114 that is specific to an approved prescription.

For example, the user interface 200 includes two prescriptions, Drug Aand Drug B. Each of the prescriptions includes textual informationassociated with the Drug A and Drug B. This textual information mayspecify constraints associated with the prescription, such as actionsthat a patient is to perform, a number of remaining refills, a time totake the prescription, and so on. This information may be received fromthe medical risk authorization system 100, for example as describedabove. Additionally, the user interface 200 may include informationobtained from public databases that can be utilized by the patient toreview detailed information associated with each prescription. As willbe described below, with respect to FIG. 2B, a patient operating theuser device 120 can interact with the user interface 200 to fill aprescription. For example, the patient can fill the prescription whilelocated at a pharmacy.

In some embodiments, the user interface 200 may present locations atwhich each pharmaceutical is available to be filled. For example, thepatient's insurance information may be accessed. Pharmacies which acceptthis insurance may then be presented. Additionally, the user device 120,or system 100, may provide functionality to enable a least cost routing.For example, the user interface 200 may present pricing informationassociated with each pharmaceutical. The pricing information may beobtained from pharmacies at which the pharmaceutical is available.Optionally, the user interface 200 may present both branded and genericversions of each drug. The user interface 200 may then presentinformation indicating whether the patient's insurance covers eachversion. Pricing information may further be reflected. For example, theuser interface 200 can indicate that a branded version of ‘Drug A’ costsa certain amount. The certain amount may include a cost per dose, a costto utilize all of the prescription, and so on. The user interface 200may also indicate costs for any generic versions of ‘Drug A’. In thisway, the patient using user interface 200 may select a choice associatedwith a preferred version of a pharmaceutical.

FIG. 2B illustrates an example user interface 200 to fill an authorizedprescription. As described above, a patient can interact with the userinterface 200 to specify a particular prescription that is to be filled.For example, the patient may be at a pharmacy to fill a particularprescription 210 (e.g., Drug A). The patient can select the particularprescription 210, and the user device 120 can provide associatedauthorization information 114 to a pharmacy system 130. For example, andas described above, the user device 120 can provide an authorizationtoken, electronically signed information, and so on, to the pharmacysystem 130. Optionally, the patient may be required by the user device120 to confirm his/her identity. For example, the patient may berequired to utilize a thumbprint reader, or the user device can utilizefacial recognition technology to confirm the patient's identity.

Optionally, the patient's user device 120 may obtain locationinformation associated with the user device 120. The user device 120 maythen utilize the location information to confirm that the user device120 is located at a pharmacy. Example location information can includeglobal navigation satellite system coordinates. For example, upon thepatient indicating that the particular prescription 210 is to be filled,the patient's user device 120 can ensure that the device 120 is locatedat a branch of a pharmacy corresponding to the pharmacy system 130. Ifthe user device 120 determines it is located within a threshold distanceof a pharmacy, the user device 120 can provide the authorizationinformation 114 to the pharmacy system 130. Similarly, the patient'suser device 120 may provide authorization information 114 via a localnetwork, such as Bluetooth, Near Field Communication, and so on, to thepharmacy system 130. In this way, it may be substantially guaranteedthat the user device 120 is physically present within a thresholddistance of the pharmacy system 130.

In some implementations, the authorization information 114 may beprovided to a particular pharmacy selected by the patient, prior to thepatient entering the pharmacy. For example, the patient can operate theuser interface 200 to select that the particular prescription 210 is tobe filled. The user interface 200 can then present pharmacies that canfill the particular prescription 210, and optionally pharmacies near thepatient or pharmacies generally utilized by the patient. The user device120 can receive a selection of a pharmacy, and the user device 120 canprovide the authorization information to a pharmacy system 130associated with the pharmacy. In this way, the pharmacy may beginpreparing the order automatically. Additionally, the pharmacy mayprepare the order based on confirmation that the prescription is valid.

Optionally, the authorization information 114 may enable an automaticopening up of a securely locked cabinet storing a filled prescription.For example, a pharmacy may fill the particular prescription 210, andplace the associated ‘Drug A’ in a locker within the pharmacy. Thepatient may then enter the pharmacy, and with his/her user device 120can provide the authorization information to the pharmacy system 130.This pharmacy system 130 may confirm the validity of the prescriptionwith the medical risk authorization system 100 as described above. Uponreceipt of approval/prescription information 142, the pharmacy system130 can cause the opening up of a secure lock. For example, the securelock may be a smart lock. Additionally, the patient may interact withthe user interface 200 to specify the particular prescription 210 whilelocated proximate to lockers included in the pharmacy. A locker thatincludes ‘Drug A’ may automatically then open, for example based on theauthorization information 114 being confirmed with the pharmacy system130. To ensure that the patient is located at the pharmacy, as describedabove the user device 120 can be required to confirm its presentlocation is within a threshold distance of the pharmacy. Additionally,the user device can provide the authorization information 114 via alocal network, such as Bluetooth or near field communications. In thisway, patients can automatically obtain prescriptions without interactingwith a pharmacist.

However, pharmacists may prefer explaining each pharmaceutical to apatient. Therefore, if the patient can automatically obtain aprescription without interacting with a pharmacist, particular speechmay therefore not be presented to the patient. Thus, optionallyparticular pharmaceuticals may be required to be picked up directly froma pharmacist. Optionally, prior to a patient being allowed to open alocker, the patient's user device 120 may be required to present textualinformation or video information describing the particular prescription210. For example, the patient may be required to watch a video andoptionally respond to a questionnaire, prior to a locker opening.

FIGS. 3A-3B illustrate speech associated with a prescription beingprovided on a user device of a patient. As described above, informationfor a prescription that is authorized for a patient may be presented ona user device 120 of the patient. However, particular prescriptions maybe associated with constraints that need to be satisfied prior to theprescription being authorized to be filled by a pharmacy. As an example,a patient may be required to hear, view, or discuss with a medicalprofessional or pharmacist, particular information.

As illustrated in FIG. 3A, a particular prescription 310 is indicated asnot being ready to be filled. For example, the presented prescriptioncan be shaded, colored, highlighted, and so on, to indicate that actionsneed to be performed. The medical risk authorization system 100 canenforce constraints associated with speech. The system 100 can provideauthorization information 114 to the patient's user device 120, and ifthere are constraints associated with the prescription, can include theconstraints in the authorization information. In this way, anapplication executing on the user device 120 can enforce the constraintsand adjust the presented user interface 300.

In the example of FIG. 3A, the user interface 300 indicates that thepatient is required to view a particular video associated with aprescription. For example, textual information 320 is included in theuser interface 300 explaining the constraints. Optionally, the userinterface 300 may indicate education and/or medical information relatedto each pharmaceutical, such that the patient may understand whichmedications are for which ailment. While the example of FIGS. 3A-3Bincludes the patient being required to view a video, as described abovedifferent speech may be presented to the patient. For example, thepatient's medical professional or pharmacist may be required to describethe associated pharmaceutical to the patient. Once the description isprovided, the patient can interact with the user interface 300 to selectthe particular prescription 320. Optionally, the user device of thepatient may obtain audio (e.g., via a microphone). The audio may beanalyzed to determine whether the speech was provided. For example, theuser device or medical risk authorization system 100 may analyze theaudio. The user interface 300 can then update with user selectableoptions for the patient to confirm that he/she received the description.

FIG. 3B illustrates speech being presented to the patient on thepatient's user device 120. As illustrated in FIG. 3A, textualinformation 320 is included in the user interface 300 indicating thepatient is required to view a video. The user interface 300 can receiveuser interactions to initiate the video, for example the patient canselect the particular prescription 310. Optionally, the patient canpress with greater than a particular force to initiate the video, orpress for greater than a threshold amount of time. As illustrated, avideo 330 can then be presented on the user device 120. As describedabove, a location at which the video is accessible may be provided tothe user device 120 from the medical risk authorization system 100, suchthat the video can be obtained (e.g., streamed) for presentation.Additionally, the medical risk authorization system 100 may stream, orcause streaming of, the video. For example, the medical riskauthorization system 100 may cause a content network to stream thevideo.

Additionally, the user device 120 can monitor the playing of the video330, and upon completion of the video 330, can provide confirmationinformation 332 to the medical risk authorization system 100.Optionally, the user device 120 can utilize a forward-facing camera toensure that the patient is viewing the video, and can ensure that theaudio and/or screen brightness are sufficient for viewing.

In some embodiments, the user device 120 may require that the userrespond to particular questions related to the speech presented to theuser. For example, the application executing on the user device mayrequest that the user fill in a portion of a text. The portion may berelated to the presented speech. Additionally, the user device mayensure that other applications, or other user interfaces, are also beingpresented by the user device. For example, it should be understood thatan example user device (e.g., a tablet) may enable a user to present twoapplications side by side, or one in a smaller window (e.g., picture inpicture). In this example, the user device 120 may ensure that only thespeech is being presented via the user device (e.g., video 330).

The system 100 can then update a transaction record associated with theparticular prescription 320 to indicate that it is authorized to befilled. The user interface 300 can then update to reflect that theparticular prescription 340 is available to be filled. For example, theuser device 120 can receive information from the medical riskauthorization system 100 confirming that the particular prescription 340is valid. As another example, the user device 120 can automaticallyupdate the user interface 300 upon determining that the video 330 wasviewed.

The application executing on the user device may enable certainfeedback, or other interactivity, with respect to pharmaceuticals theuser is utilizing. For example, with respect to opiates the user mayindicate feedback to inform effectiveness of usage. Additionally, theuser may interact with the application to trigger a pharmacy to beginpreparation of filling a prescription. For example, upon viewingparticular speech (e.g., as described above), the user device mayprovide information indicating the user can obtain a prescription. Theinformation may be optionally be provided directly to a pharmacy system(e.g., via a network). For example, the user device may obtain a networklocation associated with the pharmacy system. Additionally, theinformation may be provided to the system 100, and routed to thepharmacy system. Similarly, refills may be automatically be triggered.As described above, the user device may monitor a number of pills apatient has consumed and/or has remaining. Thus, the user device maydetect when the number of pills is below a threshold and may trigger apharmacy to prepare a new refill. The user device may then presentinformation informing the user a time at which to drive to the pharmacy(e.g., based on traffic information, time information received from thepharmacy, and so on).

FIG. 4 is a flowchart of an example process 400 for generatingtransactions in response to received prescription requests. Forconvenience, the process 400 will be described as being performed by asystem of one or more computers (e.g., the medical risk authorizationsystem 100).

At block 402, the system receives a request to authorize a prescription.As described above, the system can receive requests from medicalprofessional for approval of prescriptions. The system can ensure thatthe request is being received from valid medical professionals, andoptionally from user devices known to be associated with the medicalprofessionals.

At block 404, the system determines whether to approve the prescription.The system can optionally analyze medical history associated with apatient, to determine whether the patient would be at risk if thepatient received the associated pharmaceutical. For example, the systemcan determine whether the patient has any illnesses or allergies thatmay cause risk with the pharmaceutical. Additionally, the system cananalyze a transaction record associated with the patient to determinewhether the patient is taking pharmaceuticals that may havecontraindications with the prescription.

At block 406, the system generates transaction information associatedwith the prescription. Upon approval of the prescription, the system cangenerate transaction information confirming the prescription andassociated information. For example, the transaction information canspecify a name of the pharmaceutical, constraints associated with thepharmaceutical, and so on.

At block 408, the system generates authorization information associatedwith the prescription, and provides the information to a user device ofthe patient. As described above, the system can generate authorizationinformation to be utilized to confirm that the prescription is valid.This authorization information can then be provided by the system to thepatient's user device. For example, the system can push theauthorization information to an application associated with user accountinformation of a patient. For example, the patient can be logged into anapplication on his/her user device, and the system can push theauthorization information to the application. Since the application isexecuting on the patient's user device, the user device can be ensuredto be utilized by the patient.

The system causes presentation of speech information to the user device(block 410). The system can obtain rules associated with speech to thepatient, and cause presentation of the speech on the user device. Asdescribed above, with respect to FIGS. 3A-3B, the patient may be unableto utilize the prescription absent confirmation the speech was presentedto the patient. A transaction may further be issued indicating that theprescription is authorized to be filled.

In some embodiments, the system may enable a third party to fill aprescription of the patient. For example, the system may storeinformation identifying the third party. Example information may includea unique identifier associated with the third party, a name of the thirdparty, and so on. If the third party travels to a pharmacy, the systemmay push authorization information to a system utilized by the pharmacyconfirming the prescription. However, since this authorizationinformation may be associated with the patient, the third party may bedisallowed. Thus, in some embodiments the authorization information mayspecify the third party. Additionally, the third party may utilize anapplication associated with the system to request authorization. If thesystem determines the third party is authorized, the system can pushinformation to the pharmaceutical system confirming the authorization.

Optionally, the third party may be reflected in a blockchain (e.g., asdescribed above). In this example, identifying information associatedwith the third party may be stored in a block of the blockchain. Thus,the blockchain may be analyzed to determine whether the third party canfill the prescription. Optionally, the block may further specify typesof pharmaceuticals the third party is authorized to fill and/or typesthey are not authorized to fill. Optionally, the patient may indicatethat the third party is not authorized at a later point in time.Therefore, the blockchain may be analyzed to indicate whether the thirdparty's authorization was revoked.

In some embodiments, the system may obtain, or otherwise link with,biometric information, electronic medical record systems, and so on tolink with prescribing usage information of pharmaceuticals. The system,or an outside system, may aggregate this information to derive insightsinto outcomes of given therapeutics. For example, based on userresponses entered into their user device regarding effectiveness (e.g.,as described above). This information may be anonymized, thus ensuringprivacy.

Additional Implementation Details and Embodiments

Various embodiments of the present disclosure may be a system, a method,and/or a computer program product at any possible technical detail levelof integration. The computer program product may include a computerreadable storage medium (or mediums) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent disclosure.

For example, the functionality described herein may be performed assoftware instructions are executed by, and/or in response to softwareinstructions being executed by, one or more hardware processors and/orany other suitable computing devices. The software instructions and/orother executable code may be read from a computer readable storagemedium (or mediums).

The computer readable storage medium can be a tangible device that canretain and store data and/or instructions for use by an instructionexecution device. The computer readable storage medium may be, forexample, but is not limited to, an electronic storage device (includingany volatile and/or non-volatile electronic storage devices), a magneticstorage device, an optical storage device, an electromagnetic storagedevice, a semiconductor storage device, or any suitable combination ofthe foregoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a solid state drive, a random accessmemory (RAM), a read-only memory (ROM), an erasable programmableread-only memory (EPROM or Flash memory), a static random access memory(SRAM), a portable compact disc read-only memory (CD-ROM), a digitalversatile disk (DVD), a memory stick, a floppy disk, a mechanicallyencoded device such as punch-cards or raised structures in a groovehaving instructions recorded thereon, and any suitable combination ofthe foregoing. A computer readable storage medium, as used herein, isnot to be construed as being transitory signals per se, such as radiowaves or other freely propagating electromagnetic waves, electromagneticwaves propagating through a waveguide or other transmission media (e.g.,light pulses passing through a fiber-optic cable), or electrical signalstransmitted through a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions (as also referred to herein as,for example, “code,” “instructions,” “module,” “application,” “softwareapplication,” and/or the like) for carrying out operations of thepresent disclosure may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. Computer readable program instructions may be callable fromother instructions or from itself, and/or may be invoked in response todetected events or interrupts. Computer readable program instructionsconfigured for execution on computing devices may be provided on acomputer readable storage medium, and/or as a digital download (and maybe originally stored in a compressed or installable format that requiresinstallation, decompression or decryption prior to execution) that maythen be stored on a computer readable storage medium. Such computerreadable program instructions may be stored, partially or fully, on amemory device (e.g., a computer readable storage medium) of theexecuting computing device, for execution by the computing device. Thecomputer readable program instructions may execute entirely on a user'scomputer (e.g., the executing computing device), partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through any type of network, includinga local area network (LAN) or a wide area network (WAN), or theconnection may be made to an external computer (for example, through theInternet using an Internet Service Provider). In some embodiments,electronic circuitry including, for example, programmable logiccircuitry, field-programmable gate arrays (FPGA), or programmable logicarrays (PLA) may execute the computer readable program instructions byutilizing state information of the computer readable programinstructions to personalize the electronic circuitry, in order toperform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart(s) and/or block diagram(s)block or blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks. For example, the instructions may initially be carried on amagnetic disk or solid state drive of a remote computer. The remotecomputer may load the instructions and/or modules into its dynamicmemory and send the instructions over a telephone, cable, or opticalline using a modem. A modem local to a server computing system mayreceive the data on the telephone/cable/optical line and use a converterdevice including the appropriate circuitry to place the data on a bus.The bus may carry the data to a memory, from which a processor mayretrieve and execute the instructions. The instructions received by thememory may optionally be stored on a storage device (e.g., a solid statedrive) either before or after execution by the computer processor.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. In addition, certain blocks may be omitted insome implementations. The methods and processes described herein arealso not limited to any particular sequence, and the blocks or statesrelating thereto can be performed in other sequences that areappropriate.

It will also be noted that each block of the block diagrams and/orflowchart illustration, and combinations of blocks in the block diagramsand/or flowchart illustration, can be implemented by special purposehardware-based systems that perform the specified functions or acts orcarry out combinations of special purpose hardware and computerinstructions. For example, any of the processes, methods, algorithms,elements, blocks, applications, or other functionality (or portions offunctionality) described in the preceding sections may be embodied in,and/or fully or partially automated via, electronic hardware suchapplication-specific processors (e.g., application-specific integratedcircuits (ASICs)), programmable processors (e.g., field programmablegate arrays (FPGAs)), application-specific circuitry, and/or the like(any of which may also combine custom hard-wired logic, logic circuits,ASICs, FPGAs, etc. with custom programming/execution of softwareinstructions to accomplish the techniques).

Any of the above-mentioned processors, and/or devices incorporating anyof the above-mentioned processors, may be referred to herein as, forexample, “computers,” “computer devices,” “computing devices,” “hardwarecomputing devices,” “hardware processors,” “processing units,” and/orthe like. Computing devices of the above-embodiments may generally (butnot necessarily) be controlled and/or coordinated by operating systemsoftware, such as Mac OS, iOS, Android, Chrome OS, Windows OS (e.g.,Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, WindowsServer, etc.), Windows CE, Unix, Linux, SunOS, Solaris, Blackberry OS,VxWorks, or other suitable operating systems. In other embodiments, thecomputing devices may be controlled by a proprietary operating system.Conventional operating systems control and schedule computer processesfor execution, perform memory management, provide file system,networking, I/O services, and provide a user interface functionality,such as a graphical user interface (“GUI”), among other things.

As described above, in various embodiments certain functionality may beaccessible by a user through a web-based viewer (such as a web browser),or other suitable software program). In such implementations, the userinterface may be generated by a server computing system and transmittedto a web browser of the user (e.g., running on the user's computingsystem). Alternatively, data (e.g., user interface data) necessary forgenerating the user interface may be provided by the server computingsystem to the browser, where the user interface may be generated (e.g.,the user interface data may be executed by a browser accessing a webservice and may be configured to render the user interfaces based on theuser interface data). The user may then interact with the user interfacethrough the web-browser. User interfaces of certain implementations maybe accessible through one or more dedicated software applications. Incertain embodiments, one or more of the computing devices and/or systemsof the disclosure may include mobile computing devices, and userinterfaces may be accessible through such mobile computing devices (forexample, smartphones and/or tablets).

Many variations and modifications may be made to the above-describedembodiments, the elements of which are to be understood as being amongother acceptable examples. All such modifications and variations areintended to be included herein within the scope of this disclosure. Theforegoing description details certain embodiments. It will beappreciated, however, that no matter how detailed the foregoing appearsin text, the systems and methods can be practiced in many ways. As isalso stated above, it should be noted that the use of particularterminology when describing certain features or aspects of the systemsand methods should not be taken to imply that the terminology is beingre-defined herein to be restricted to including any specificcharacteristics of the features or aspects of the systems and methodswith which that terminology is associated.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certainfeatures, elements, and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

The term “substantially” when used in conjunction with the term“real-time” forms a phrase that will be readily understood by a personof ordinary skill in the art. For example, it is readily understood thatsuch language will include speeds in which no or little delay or waitingis discernible, or where such delay is sufficiently short so as not tobe disruptive, irritating, or otherwise vexing to a user.

Conjunctive language such as the phrase “at least one of X, Y, and Z,”or “at least one of X, Y, or Z,” unless specifically stated otherwise,is to be understood with the context as used in general to convey thatan item, term, etc. may be either X, Y, or Z, or a combination thereof.For example, the term “or” is used in its inclusive sense (and not inits exclusive sense) so that when used, for example, to connect a listof elements, the term “or” means one, some, or all of the elements inthe list. Thus, such conjunctive language is not generally intended toimply that certain embodiments require at least one of X, at least oneof Y, and at least one of Z to each be present.

The term “a” as used herein should be given an inclusive rather thanexclusive interpretation. For example, unless specifically noted, theterm “a” should not be understood to mean “exactly one” or “one and onlyone”; instead, the term “a” means “one or more” or “at least one,”whether used in the claims or elsewhere in the specification andregardless of uses of quantifiers such as “at least one,” “one or more,”or “a plurality” elsewhere in the claims or specification.

The term “comprising” as used herein should be given an inclusive ratherthan exclusive interpretation. For example, a general purpose computercomprising one or more processors should not be interpreted as excludingother computer components, and may possibly include such components asmemory, input/output devices, and/or network interfaces, among others.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it may beunderstood that various omissions, substitutions, and changes in theform and details of the devices or processes illustrated may be madewithout departing from the spirit of the disclosure. As may berecognized, certain embodiments of the inventions described herein maybe embodied within a form that does not provide all of the features andbenefits set forth herein, as some features may be used or practicedseparately from others. The scope of certain inventions disclosed hereinis indicated by the appended claims rather than by the foregoingdescription. All changes which come within the meaning and range ofequivalency of the claims are to be embraced within their scope.

What is claimed is:
 1. A computer system comprising one or more computerprocessors configured to execute software code to perform operationscomprising: receiving a request to authorize a prescription for apatient, the request being from a medical professional and the requestbeing received via a network; generating transaction informationassociated with the prescription, the transaction information specifyingthat the patient is authorized to obtain an associated pharmaceutical,and the transaction information being included in a transaction recordassociated with the patient; generating authorization informationassociated with the prescription, the authorization information beingprovided to a user device of the patient, and the authorizationinformation enabling confirmation by an outside system that theprescription is authorized; and cause presentation, via an interactiveuser interface on the user device, of speech information associated withthe prescription, wherein upon confirmation of presentation of thespeech information, the transaction record associated with the patientis updated.